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Status of this Memo 


This document specifies an Internet standards track protocol for the 
Internet community, and requests discussion and suggestions for 


improvements. Please refer to the current edition of the "Internet 
Official Protocol Standards" (STD 1) for the standardization state 
and status of this protocol. Distribution of this memo is unlimited. 
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Abstract 


The Layer 2 Tunneling Protocol (L2TP) defines a mechanism for 
tunneling Point-to-Point Protocol (PPP) sessions. It is common for 
these PPP sessions to be established using modems connected over the 
public switched telephone network. 


One of the standards governing modem operation defines procedures 
that enable a client modem to put the call on hold and later, re- 
establish the modem link with minimal delay and without having to 
redial. While the modem call is on hold, the client phone line can 
be used to place or receive other calls. 


The L2TP base protocol does not provide any means to signal these 
events from the L2TP Access Controller (LAC), where the modem is 
physically connected, to the L2TP Network Server (LNS), where the PPP 
session is handled. 


This document describes a method to let the LNS know when a client 
modem connected to a LAC has placed the call on hold. 
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1. Introduction 


The Layer 2 Tunneling Protocol (L2TP) [RFC2661] defines a general 
purpose mechanism for tunneling Point-to-Point Protocol (PPP) [STD51] 
sessions over various media. By design, the operation of L2TP is 
insulated from the details of the media from which the PPP session 
originated. 


It is common for PPP sessions to be established using modems 
connected over the public switched telephone network. The ITU-T 
Recommendation V.92 [V92] is one of the standards governing modem 
operation and it defines procedures that enable a client modem to put 
the call on hold and later, re-establish the modem link without 
having to redial. While the modem call is on hold, the client phone 
line can be used for another phone call. 


The L2TP base protocol does not provide any means to signal these 
events from the L2TP Access Controller (LAC), where the modem is 
physically connected, to the L2TP Network Server (LNS), where the PPP 
session is handled. It may be desirable for this information (which 
is available only on the LAC) to be provided to the LNS. 
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This document provides additional L2TP AVPs and control messages that 
may be used to communicate some modem information from the LAC to the 
LNS. However, it does not define what, if anything, the LNS should 
do with this information. A sample of the possible actions that an 
LNS may consider are listed in section 5. 


1.1. Specification of Requirements 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", “SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in BCP 14, RFC 2119 
[BCP14]. 

1.2. Terminology 


Definition of terms used in this document may be found in the L2TP 
Protocol document [L2TP]. 


2. Protocol Operation 


The typical dial in topology looks like this: 


+----- + { } +---------—- + [ IP ] 
| |- [M] ----- { PSTN }----- ESMI ile neegeate [ network ] 
a + { } Peis t [ ] 
Remote NAS 

System 


M is the client modem and may be an integral part of the Remote 
System. If this modem implements V.92, it can ask the server modem 
SM (a part of the NAS) whether the call can be placed on-hold for 
some period of time. 


If the server modem agrees, the client modem can signal the PSTN to 
place the call on-hold (usually, a flash hook). The user at the 
remote system can then use the same POTS line where the client modem 
is connected to make or receive another call. 


In the above scenario, the server modem module can notify the rest of 
the NAS of these events via its usual signaling mechanism. The NAS 
layers can then act on this information as desired. See section 5. 
for a sample list of possible actions. 
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In the case of L2TP, this document looks at this particular topology: 


+----- + { } tiren F [ packet ] prne + [ home ] 
| |-[M]---{ PSTN }---[SM] |...[ network ]...| |...[ network ] 
VESERA + { } Toos + [ ] tences + [ ] 
Remote LAC LNS 

System 


If the LAC implements the functionality described here, it can signal 
to the LNS when the client modem has gone on-hold and when it comes 
back online. 


This document does not define what, if anything, the LNS should do 
with this information. A sample of the possible actions that an LNS 
MAY consider are listed in section 5. However, the LNS MUST NOT stop 
processing otherwise valid data packets arriving from the LAC, 
regardless of the current state of the modem on-hold indications. 


2.1. Typical Modem on Hold Usage Scenario 
A user connects to his Internet service provider with a V.92-capable 


modem. He then starts downloading a big file which will take several 
minutes to complete. 


While the file is being downloaded, a friend calls him. If the user 
has call waiting enabled, his modem can let him know of the incoming 
call and he can choose to either pick up the incoming call or reject 
it. Let’s say he chooses to pick up the phone to talk to his friend, 
for example because he recognized the caller’s phone number. 


Before the user picks up his phone, he tells his modem to go on hold 
and switch to the incoming call (usually signaled with a "flash- 
hook"). His modem will then notify the server modem (attached to the 
LAC) that it is about to go on hold. If the server modem agrees, the 
client performs a flash hook so the user can talk to his friend. 


After talking to his friend, the user let’s his modem know that it 
can return to the original call (where the server modem has been 
patiently waiting). After another flash hook, the modems are 
connected again and the download can continue. 


2.2. Capability Negotiation 


A LAC MUST NOT send a Modem Status (MDMST) control message to an LNS 
that has not indicated the capability of processing such control 
messages. This capability is indicated by adding a "Modem On-Hold 
Capable" AVP on the SCCRQ or SCCRP sent to the LAC when the tunnel is 
brought up. 
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2.3. Modem On-Hold 


When the client modem requests the LAC to go on-hold, the LAC SHOULD 
send a MDMST control message to the LNS with the H (Hold) field set 
to 1 and the negotiated maximum on-hold time. 


2.4. Modem Online 


When the client modem returns back online after having gone on-hold, 
the LAC SHOULD send a MDMST control message to the LNS with the H 
(Hold) field set to 0. The LAC MUST send this message if it has 
previously sent a MDMST message with the H (Hold) field set to 1. 


3. New Control Messages 


The following control messages MUST be sent with the M-bit in the 
Message Type AVP set to 0 to prevent interoperability issues. 


Messages with unknown values in the Message Type AVP with the M-bit 
set to 0 should be ignored by compliant L2TP peers [RFC2661]. 


3.1. Modem-Status (MDMST) 


The Modem-Status (MDMST) control message is used by the LAC to notify 
the LNS when the client modem on-hold status changes. 


The MDMST control message MUST NOT be sent to peers that have not 
included the "Modem On-Hold Capable" AVP in their Start-—Control- 
Connection-Request (SCCRQ) or Start-Control-Connection-Reply (SCCRP) 
control messages. 


Furthermore, the MDMST control message can only be sent after session 
establishment is successful (i.e., after the LAC has sent either an 
Incoming-Call-Connected (ICCN) or an Outgoing-Call-Connected (OCCN) 
control message), and before the session ends from the LAC’s point of 
view (i.e., before the LAC has sent or received a Call-Disconnect- 
Notify (CDN) control message). 


Note that due to protocol race conditions, it is possible for a LAC 
to send a MDMST control message about the same time that the LNS is 
sending a CDN. An LNS MUST ignore MDMST control messages received 
after sending a CDN. 


An LNS MUST ignore redundant modem status reports. 
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This control message is encoded as follows: 


Vendor ID = 0 (IETF) 
Attribute Type = 17 


The following AVPs MUST be present in the MDMST control message: 


Message Type 
Modem On-Hold Status 


The M-bit on the Message Type AVP for this control message MUST be 
set to 0. 


4. New Attribute Value Pairs 


The following sections contain a list of the new L2TP AVPs defined in 
this document. 


4.1. Modem On-Hold Capable AVP 


The Modem On-Hold Capable AVP, Attribute Type 53, indicates that the 
sender (an LNS) is capable of receiving MDMST control messages. This 
AVP MUST be included on the SCCRQ or SCCRP control messages to 
indicate that the sender implements this specification. 


This AVP has no Attribute Value field. 


This AVP MAY be hidden (the H-bit on the AVP header MAY be 0 or 1). 
The M-bit for this AVP MUST be set to 0. The Length is 6. 


4.2. Modem On-Hold Status AVP 


The Modem On-Hold Status AVP, Attribute Type 54, indicates the 
current on-hold status of the client modem. This AVP MUST be present 
on the MDMST control message. 


The Attribute Value field for this AVP has the following format: 


0 1 

Oe de 2? Bi 4 25 sei e 9-02 Ts 2) 3) 4S 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 
|u] reserved |Timeout | 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 


The Modem On-Hold Status AVP is a 16-bit quantity, containing two 

fields that indicate whether the client modem has placed the call 

on-hold and the maximum amount of time that the call is allowed to 
remain on-hold. 
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The H (Hold) field is a single bit that indicates whether the client 
modem has placed the call on-hold. If the H (Hold) field is 1, the 
client modem is on-hold. If the H (Hold) field is 0, the client 
modem is back online. 


The Timeout field is a 4 bits quantity that indicates the negotiated 


maximum amount of time that the call can remain on-hold. It is valid 
only if the H (Hold) field is 1 and MUST be ignored if the H (Hold) 
field is 0. The values for the Timeout field are defined in [V92] 


and they are reproduced here for easy reference: 


Bits Decimal Meaning 
0000 0 Reserved 
0001 1 10 seconds 
0010 2 20 seconds 
0011 3 30 seconds 
0100 4 40 seconds 
0101 5 1 minute 
0110 6 2 minutes 
0111 7 3 minutes 
1000 8 4 minutes 
1001 9 6 minutes 
1010 10 8 minutes 
1011 11 12 minutes 
1100 12 16 minutes 
1101 T3 No limit 
1110 14 Reserved 
TLEL 15 Reserved 


Bits 1 through 11 are reserved. These bits MUST be set to 0 when 
sending this AVP and MUST be ignored on reception. 


This AVP MAY be hidden (the H-bit on the AVP header MAY be 0 or 1). 
The M-bit for this AVP MUST be set to 0. The Length is 8. 


5. Sample LNS Actions 


The specific actions taken by an LNS upon receipt of a Modem On-Hold 
Status AVP are implementation dependent. This document does not 
mandate what, if anything, the LNS should do with this information. 


The choice of actions taken by the LNS may have an impact on higher 
layer protocols. For example, TCP connections and other connection- 
oriented applications may timeout or disconnect during the on-hold 
time. The impact that those choices may have on these or other 
protocols is not addressed by this document. 
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The following list is a sample of possible actions that an LNS 
implementation might consider. Note that some of these actions are 
not really alternatives, as some of the possibilities preclude 
others. 


* Temporarily stop polling protocols such as LCP Echo Requests, Link 
Quality Monitoring (LOM), Multilink PPP (MP), etc. 

Drop data packets directed to the now on-hold remote client. 

Start a new accounting session, to account for the on-hold time. 
Stop or hold accounting until the modem returns online again. 
Start a separate time accounting for the time that the modem is on 
hold. 


+ F + a 


Here are a few things that an LNS should probably NOT do: 


* Buffer data packets directed to the now on-hold remote client. 
Reason: How many data packets should be buffered? What would be 
the impact on higher layer protocols such as TCP? What 
would be the impact caused by the delay introduced when 
the client returns online again? 


* Answer TCP keepalives in lieu of the client. 
Reason: It may interfere with TCP’s recovery once the client 
returns online. 


* Stop processing otherwise valid data packets from the client. 
Reason: There is a race condition between the notification of 
the modem returning online and the first packet from the 
client because they are delivered on independent channels. 
Dropping valid client packets may lead to a slower 
recovery after returning online due to the forced retries. 
6. IANA Considerations 


This document requires one new L2TP "Message Type" number to be 
assigned by IANA: 


17, Section 3.1., Modem Status 
It also requires two new "AVP Attributes" to be assigned by IANA: 


53, Section 4.1., Modem On-Hold Capable AVP 
54, Section 4.2., Modem On-Hold Status AVP 


The Modem On-Hold Status AVP contains a set of reserved bits (bits 1 
through 11) that are assigned by IANA through IETF Consensus [BCP26]. 
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7. Security Considerations 


The integrity and confidentiality of the method described in this 
document relies on the underlying L2TP security mechanisms. The new 
control message and AVPs are intended to indicate when a client modem 
has gone on-hold and cannot receive data. It does not define what, 
if anything, the LNS should do with this information. A sample of 
possible actions that an LNS may consider are listed in section 5. 


It is believed that the defined extension does not provide 
information that would be useful to an attacker, and as such, it 


should not pose a threat to system security. 


If desired, the new AVPs MAY be hidden as described in section 4.3 of 


[RFC2661]. 
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Appendix A: Vendor Specific Assignments 
THIS SECTION IS NOT NORMATIVE 


Early implementations of this specification used vendor-specific 


values for the new control message and AVPs. This appendix describes 
those initial vendor-specific assignments for historical reference 
only. 


The following table shows the vendor-specific assignments: 


Vendor Attr Attr 


ID Type Value Equivalent to 
Control message: 
Modem-Status 529 0 2 Section 3.1. 
AVP: 
Modem On-Hold Capable 529 2 none Section 4.1. 
Modem On-Hold Status 529 3 een Section 4.2. 
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or assist in its implementation may be prepared, copied, published 
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This document and the information contained herein is provided on an 
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